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I n the previous article of this series, we opened up a 
discussion of testing issues when using Smalltalk. We 
discussed aspects of GUI and Model testing, and we 
provided a definition of a software component as code, 
documentation, and tests. In this article, we discuss the 
testing of these components in detail, including the role 
of regression testing. 

I n discussing components, it is very important that we 
include the ability to construct complex components as 
aggregations of simpler components, because this isvery 
common and allows us to define components in a recur¬ 
sive manner. Our prior discussion of a software compo¬ 
nent emphasized the role of the interface in the defini¬ 
tion of the component. The interface must be supplied 
for an aggregate or complex component, as wel I as a sim¬ 
ple component. This brings us to a problem that I refer to 
as the Public/ Private Problem. 

In Figure 1, we show a simple diagram of three classes, 
A, B, and C, some numbered methods, 1 to 8, and two 
message sends from outside. Note that the method num¬ 
bers are arbitrary. 

Smalltalk currently defines the interface through the 
public/ private "attribute" of the methods. In Figure 1, meth¬ 
ods 7,1, 4, 3 and 6 would be considered public if the two 
message sends were the only way the classes are used. 

Now consider Figure 2. In thisfigure, we have construct¬ 
ed two components, I and II,from the supplied classes. 

Note that from the point of view of component I, the 
interface is land 6. From the point of view of component 
11, the i nterface is 6 and 7. 

Let’s look at Class A methods. 
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We are using a simple dot notation to indicate the inter¬ 
section of the method and the component: 

<co mpo n en t >. <c I ass>( <sel ecto r>) 

From this diagram it is easy to see that the public/ private 
attribute of a method is not a useful construct in deter¬ 
mining the interface of a component. Each component 
must define its own public methods (i.e., its interface). We 
have found that the identification of this interface is crit¬ 
ical to the building of reusable components. 

None of the currently available code control systems 
for Smalltalk support this view of the interface definition 
of a component. At most they support the public/ private 
attribute of a method. This situation makes it difficult to 
adequately specify and test a component. I would like to 
encourage the vendors to add such support to thei r tools. 
Such support would move us a long way in the direction 
of bei ng able to clearly define components. 

Note that if the packagi ng changes, then the i nterfaces 
may change fairly dramatically. For example, if compo- 
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nent I is changed to be classes A and C rather than class¬ 
es A and B. As we would expect, the interfaces of II 
remain II.C(7) and II.A(6). The interface of I, however, 
changes noticeably. I.C(7) and I.A(4) are added to the 
interfaces, I.A(6) does not change its status, and I.A(l) is 
no longer part of the interface. 

We can make one further observation regarding ag¬ 
gregate components. If a method defined in a compo¬ 
nent, C, is private, then it must remain private in any ag¬ 
gregate component that contains the component C. This 
restriction is often violated, as "interesting" methods are 
discovered deep within a component structure. One 
might consider such usage as behavior "leakage," which 
is analogous to memory leakage. The tool support 
requested above would make it possible to detect such 
leakage. 

This view of the public/ private problem also solves the 
difficult problem of considering methods in a class hier¬ 
archy. If a component, CA, holds an abstract class, A, and 
another component, CS, holds a concrete subclass, S, 
then how do we handle methods that are defined in the 
class A but only used within the class S? Our view is that 
all such methods must be considered public to the com¬ 
ponent CA, just as any methods in S that are required in A 
to "complete" the abstract class should be considered 
public to the component CS. 

All of this is a bit easier to think about if we just con¬ 
sider a class as a component consisting of a bunch of 
methods. Thinking of classes in this way also makes it 
easier to consider loose methods (class extensions). 

TESTING COMPONENTS 

With this enhanced definition of a component and its 
interface, it is now possible to discuss how we might test a 
component. 

Testing only the interface, with no knowledge of the 
internals, is called black box testing. Most practitioners 
consider black box testing insufficient because it is typi¬ 
cally impossible to test all possible states. Testing with 
knowl-edge of the internals is called white box testing. A 
suggestion has been madethattestingthe interface with a 
"little" knowledge of the internals should be called gray 
boxtesting! 

Thedecisionastothetypeoftesting(i.e., black, gray, or 
blackbox) dependson thetestingjob beingperformed. Let 
us consider these three major tasks performed with tests: 
•UnitTesting 
•InterfaceTesting 
• Aggregati on Testi ng 

Unit testing is typically performed by the developer and 
should verify that the component functions as designed. 
This usually means white box testing or, at least, gray box 
testing. 

Interface testing is a term I use to mean testing only 
the interface. It is important that interface tests are pro¬ 
vided to support consolidation and redesign activities. 
SQA should ensure that interface testing completely ex¬ 
ercise the interface of the component. 


Aggregation testing is the term that I use when testing 
aggregationsor complex components. I n aggregati on test¬ 
ing, interface testing of the subcomponents isfollowed by 
theunittestingofthecomponentitself. In otherwords,first 
test if the pieces still work and then determine if they are 
working together correctly; bottom-up testing as it were. 

In our example, here is the testing sequence for com- 


ponent II: 

Unit 

ClassA 

Unit 

Class B 

Interface 

ClassA* 

Interface 

Class B* 

Unit 

Component 1* 

Unit 

Class C 

Interface 

Component 1** 

Interface 

Class C** 

Unit 

Component II** 

Interface 

Component II 


The asterisk indicates the aggregation test of component 
I and double asterisks indicate the aggregation test of 
component II. 

Of course, in practice, distinctions are never this clear. 
However, they should be considered when considering 
the effi cacy of testi ng. 

The above sequence works fine when fixing bugs and 
when adding functions. For each version, existing tests 
are used as is or are expanded to test for bugs and the 
new functions. 

This is classic regression testing, which can be auto¬ 
mated. Automation helps keep systems "no worse" than 
they were in the prior build. Regression testing in Small¬ 
talk systems appears to have more value than regres¬ 
sion testing in classical software development. While I 
am not exactly sure why, I suspect that it is because 
inheritance and the distributed nature of Smalltalk sys¬ 
tems make the impact of change more difficult to pre¬ 
dict. The developer doesn’t know the whole system. 

Regression testing does not work as well during con¬ 
solidation or refactoring. Say component I is significantly 
changed so that it no longer useclassesA and B, but rather 
uses classes X and Y. Call this new component I '.Also as¬ 
sume that the interface to component I' remains un¬ 
changed from I .Thetestsequenceforcomponentrisnow 


Unit 

ClassX 

Unit 

ClassY 

Interface 

ClassX 

Interface 

ClassY 

Unit 

Component 1' 

Interface 

Component 1' 


The key to note is that the last test is the same as in the 
original testing. In other words, Interface(l) is the same 
test as Interface!I'), because the interface has not 
changed. If unit and interface testing are combined, as 
manyfolksdo, then this is not true; Unit(l') isclearly not 
thesameasllnit(l). 

In practice, this means that if the tests are not sep¬ 
arated into the unit and interface components, tests 
have no utility in verifying if the new version can replace 
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the old. In practice this happens all the time. The devel¬ 
oper changes class A, changes the class A tests to reflect 
the change, and then is puzzled when someone else’s 
use of class A breaks. This is because the developer 
changed the interface and then just changed the tests to 
match. 

Good design and the enforcement of interface con¬ 
tracts reduces the exposure to this type of trouble. Good 
interface tests can be used to ensure that interface con¬ 
tracts are kept up. 

As more software is developed by top-down construc¬ 
tion, combining existing components in new ways, the 
importance of interface testing becomes greater. No 
longer can the developer of a component use SENDERS to 
find all the clients of that component. In the extreme 
view, if the interface changesin any way it is really a new 
component. New and improved perhaps, but still a new 
component. 

This article has explored the public/ private, proposed a 
solution, and then used that solution to define unit, 
interface, and aggregate testing. In our next article, we 
will discuss roles in the testing process with a particular 
focus on changes in time. M 
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